refactor(buildContext): added displayName and fixed useInnerContext branch handling - #277
refactor(buildContext): added displayName and fixed useInnerContext branch handling#277wo-o29 wants to merge 3 commits into
Conversation
There was a problem hiding this comment.
Pull Request Overview
This pull request refactors the buildContext utility function to improve type safety and debugging experience. The changes address issues with null handling in TypeScript generics and enhance developer experience with better Provider naming.
- Fixed TypeScript type inconsistencies by standardizing on
nullinstead of mixingnullandundefined - Added displayName to Provider components for better debugging in React DevTools
- Updated documentation examples to use proper default values instead of
null
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/utils/buildContext/buildContext.tsx | Core implementation with type safety fixes and displayName addition |
| src/utils/buildContext/buildContext.md | Updated English documentation example |
| src/utils/buildContext/ko/buildContext.md | Updated Korean documentation example |
Comments suppressed due to low confidence (1)
src/utils/buildContext/buildContext.tsx:17
- The JSDoc example still shows
nullas the second parameter, but this is now invalid according to the updated function signature. This should be updated to match the corrected examples in the documentation files, such as{ title: '' }.
* const [Provider, useContext] = buildContext<{ title: string }>('TestContext', null);
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #277 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 37 37
Lines 1093 1094 +1
Branches 324 324
=========================================
+ Hits 1093 1094 +1 🚀 New features to boost your workflow:
|
|
Sorry for the slow response 🙇 I went through all three of your PRs together, and the issues you found are real. Rather than rebasing each one onto the current layout, I folded them into a single PR with you as co-author: #486 Closing all three in favor of above pr |
Overview
buildContextexample documentIn the example,
nullis passed as the second argument, but since the signature ofbuildContextis as follows,nullcannot be passed.Also, since we used the
<{ title: string }>generic type, we cannot initialize it withnull.Currently, it is difficult to debug because there is no displayName for Provider, so the displayName is specified using the
contextNameprop.Since the type declaration of Context is as follows, when reading the Context with
useContext, it is inferred asContextValuesType | undefined.However, if there are no values received as props within the Provider,
nullis returned. If props exist, the received props are returned.Therefore, when reading
useContext,ContextValuesType | nullis actually returned, but the type system infersContextValuesType | undefined.To solve this complex and tangled type problem, the type of context was unified to
ContextValuesType | nullso that onlynullcan be handled.Since the type of
defaultContextValuesis<ContextValuesType extends object> | undefined,nullcannot be provided, so there is no need to handle the case ofnull.Checklist
yarn run fixto format and lint the code and docs?yarn run test:coverageto make sure there is no uncovered line?